Apparatus for indirect directory searches and method therefor

ABSTRACT

A system and method for performing an indirect directory search is implemented. In the indirect search, entry attributes that reference other objects may selectively be searched. An attribute syntax for a distinguished name (DN) which is a reference is defined. If an attribute value belonging to an attribute corresponding to the reference syntax is in an entry found by the search, the value points to another entry in the directory. The attributes (members) of the entry pointed to are selectively retrieved, depending on parameters in the search request.

CROSS REFERENCE TO RELATED APPLICATION

[0001] The present invention is related to the following U.S. patentapplication which is hereby incorporated herein by reference: Ser. No.09/______ entitled “Data Processing System and Method For Multi-LevelDirectory Searches” (Attorney Docket No. AUS9-2000-0732-US1).

TECHNICAL FIELD

[0002] The present invention relates in general to data processingsystems, and in particular, to directory searching in data processingsystems.

BACKGROUND INFORMATION

[0003] Information describing the various users, applications, files,printers and other resources accessible in a multi-user environment isoften collected into a special database which may be referred to as adirectory. The Lightweight Directory Access Protocol (LDAP) is an openarchitecture set of protocols for accessing and updating information ina directory. (LDAP version 2 is defined in Request for Comments (RFC)1777, and LDAP version 3 is specified in RFC 2251, December 1997(copyright, The Internet Society, 1997)). RFC 1777 and RFC 2251 arehereby incorporated herein by reference.

[0004] In the LDAP, the basic unit of information stored in thedirectory is referred to as an entry. Entries represent objects ofinterest, for example, in a multi-user dataprocessing systemenvironment, people, servers, organizations, etc. Entries are composedof a collection of attributes that contain information about the object.Every attribute has a type and one or more values. Attribute types areassociated with a syntax. The syntax specifies what kind of value can bestored. Directory entries are arranged in a tree structure or hierarchy.(Entries may also be referred to as nodes, and the terms may be usedinterchangeably herein.) The organization of the tree structure and thetype of objects that can be stored in the directory as well as theirattributes are defined in the schema for the objects. The set of schemadefining a particular directory provides a road map to the organizationof the directory. (Note, that the schema do not refer to the instancesof entries in a particular directory.) Additionally, the data store thatcontains the information constituting the directory may be implementedusing a multiplicity of mechanisms. The LDAP itself does not specify aparticular storage mechanism. For example, the directory storagemechanism may be implemented using flat files, a binary tree (b-tree) ora relational database.

[0005] Directory entry information is retrieved by formulating an LDAPsearch. A search within the directory hierarchy is specified in LDAP bya “distinguished name” (DN). A DN (discussed further hereinbelow) is aunique name that unambiguously identifies a single entry within thedirectory hierarchy. The value of an attribute associated with aparticular entry may itself be a DN. If information in the entriesreferred to by these DNs is to be retrieved, the distinguish nameconstituting the value of the attribute in the first search must beretrieved, and a new search initiated. For each such DN contained in anentry, a separate search must be performed. Consequently, there is aneed in the art for mechanisms for retrieving directory informationassociated with a referenced object in another directory entry that donot necessitate the initiation of multiple search requests.

SUMMARY OF THE INVENTION

[0006] The aforementioned needs are addressed by the present invention.Accordingly, there is provided, in a first form, a search method. Themethod determines if a first parameter has a first predetermined value.If the first parameter has said first predetermined value, the methodreturns a value of each of one or more selected members of a first node,said first node being referenced by a value of a first member of asecond node in response to said first member of said second node havinga predetermined type.

[0007] There is also provided, in a second form, a computer programproduct. The program product includes a program of instructions fordetermining if a first parameter has a first predetermined value. Theprogram product also contains instructions for returns a value of eachof one or more selected members of a first node, said first node beingreferenced by a value of a first member of a second node in response tosaid first member of said second node having a predetermined type, ifthe first parameter has the first predetermined value.

[0008] Additionally there is provided, in a second form, a dataprocessing system. The system has circuitry operable for determining ifa first parameter has a first predetermined value. Also included iscircuitry operable for, if the first parameter has the firstpredetermined value, returning a value of each of one or more selectedmembers of a first node, the first node being referenced by a value of afirst member of a second node in response to the first member of thesecond node having a predetermined type.

[0009] The foregoing has outlined rather broadly the features andtechnical advantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding of the present invention, andthe advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings, inwhich:

[0011]FIG. 1 illustrates a representative LDAP directory service system;

[0012]FIG. 2 illustrates, in block diagram form, a data processingsystem implemented in accordance with an embodiment of the presentinvention,

[0013]FIG. 3 illustrates, in flowchart form, a methodology in accordancewith an embodiment of the present invention; and

[0014]FIG. 4 schematically illustrates a simplified directory which maybe used in an embodiment in accordance with the principles of thepresent invention.

DETAILED DESCRIPTION

[0015] The present invention provides a system and method for performingan indirect directory search in which entry attributes that referenceother objects may selectively be searched. An attribute syntax for adistinguished name (DN) which is a reference is defined. If an attributevalue belonging to an attribute corresponding to the reference syntax isin an entry found in the search, the value is a pointer to another entryin the directory. The attributes (members) of the entry pointed to maybe selectively retrieved, in accordance with parameters in the searchrequest.

[0016] In the following description, numerous specific details are setforth such as specific distinguished names, etc. to provide a thoroughunderstanding of the present invention. However, it will be obvious tothose skilled in the art that the present invention may be practicedwithout such specific details. In other instances, well-known circuitshave been shown in block diagram form in order not to obscure thepresent invention in unnecessary detail. For the most part, detailsconcerning timing considerations and the like have been omitted in asmuch as such details are not necessary to obtain a completeunderstanding of the present invention and are within the skills ofpersons of ordinary skill in the relevant art.

[0017] Refer now to the drawings wherein depicted elements are notnecessarily shown to scale and wherein like or similar elements aredesignated by the same reference numeral through the several views.

[0018] A block diagram of a representative LDAP directory service inwhich the present invention may be implemented is shown in FIG. 1. Apreviously described, LDAP is the lightweight directory access protocol.This protocol may be implemented as either a front end to the X.500directory service, or as a standalone directory service. According tothe protocol, a client machine 10 makes a TCP/IP connection to an LDAPserver 12 through network 11, sends requests and receives responses.LDAP server 12 supports a directory 21 as illustrated in a simplifiedform in FIG. 1. Each of the client and server machines further include adirectory “runtime” component 25 for implementing the directory serviceoperations as will be described below. As previously discussed, thedirectory 21 is based on the concept of an “entry” 27, which containsinformation about some object (e.g., a person). Entries are composed ofattributes 29, which have a type and one or more values. Each attribute29 has a particular syntax that determines what kinds of values areallowed in the attribute (e.g., ASCII text, binary characters, and thelike) and how these values are constrained during a particular directoryoperation.

[0019] The directory tree (referred to in the LDAP as the DirectoryInformation Tree (DIT)) is organized in a predetermined manner, witheach entry uniquely named relative to its sibling entries by a “relativedistinguished name” (RDN). An RDN is derived from the attributes of thecorresponding directory entry. An RDN may typically have the form<attribute name>=<attribute value>. According to the protocol, aglobally unique name for an entry, the distinguished name (DN), may be aconcatenation of the RDN sequence from a given entry to the tree root.RDNs, and DNs will be further discussed hereinbelow, in the context ofan LDAP search, in conjunction with FIG. 4.

[0020] Referring now to FIG. 2, an example is shown of a data processingsystem 200 which may be used for the invention. System 200 may, forexample, be used in an embodiment of client 10, or server 12, FIG. 1.The system has a central processing unit (CPU) 210, which is coupled tovarious other components by system bus 212. Read only memory (“ROM”) 216is coupledto the systembus 212 and includes a basic input/output system(“BIOS”) that controls certain basic functions of the data processingsystem 200. Random access memory (“RAM”) 214, I/O adapter 218, andcommunications adapter 234 are also coupled to the system bus 212. I/Oadapter 218 may be a small computer system interface (“SCSI”) adapterthat communicates with a disk storage device 220. Communications adapter234 interconnects bus 212 with an outside network enabling the dataprocessing system to communicate with other such systems. Input/Outputdevices are also connected to system bus 212 via user interface adapter222 and display adapter 236. Keyboard 224, track ball 232, mouse 226 andare all interconnected to bus 212 via user interface adapter 222. (Anartisan of ordinary skill would appreciate that implementation of system200 as a server, such as server 12, FIG. 1, may omit one or more I/Odevices.) Display monitor 238 is connected to system bus 212 by displayadapter 236. In this manner, a user is capable of inputting to thesystem throughout the keyboard 224, trackball 232 or mouse 226 andreceiving output from the system via display 238.

[0021] Preferred implementations of the invention includeimplementations as a computer system programmed to execute the method ormethods described herein, and as a computer program product. Accordingto the computer system implementation, sets of instructions forexecuting the method or methods are resident in the random access memory214 of one or more computer systems configured generally as describedabove. Until required by the computer system, the set of instructionsmay be stored as a computer program product in another computer memory,for example, in disk drive 220 (which may include a removable memorysuch as an optical disk or floppy disk for eventual use in the diskdrive 220). Further, the computer program product can also be stored atanother computer and transmitted when desired to the user's work stationby a network or by an external network such as the Internet. One skilledin the art would appreciate that the physical storage of the sets ofinstructions physically changes the medium upon which it is stored sothat the medium carries computer readable information. The change may beelectrical, magnetic, chemical, biological, or some other physicalchange. While it is convenient to describe the invention in terms ofinstructions, symbols, characters, or the like, the reader shouldremember that all of these and similar terms should be associated withthe appropriate physical elements.

[0022] Note that the invention may describe terms such as comparing,validating, selecting, identifying, or other terms that could beassociated with a human operator. However, for at least a number of theoperations described herein which form part of at least one of theembodiments, no action by a human operator is desirable. The operationsdescribed are, in large part, machine operations processing electricalsignals to generate other electrical signals.

[0023] Refer now to FIG. 3 illustrating, in flowchart form, indirectsearch process 300 in accordance with the principles of the presentinvention. In step 302, process 300 waits for a search request. Searchrequests in an LDAP message as defined in the LDAP Specification, RFC2251. If a search request is received, the search parameters areretrieved from the request, step 304. Recall that the directorystructure is in the form of a tree, the DIT, in which each node isuniquely named relative to its siblings by an RDN. Each node may beidentified by a globally unique name, the DN, formed by concatenating,in accordance with a syntax specified in the LDAP, RDNs. An LDAP searchis specified by a set of parameter values. The starting point of thesearch, called the base object, is specified by a DN for the baseobject. (The base object is a node within the DIT.) Additionally, theLDAP search parameters may include the search scope. The scope definesthe depth of the search within the DIT relative to the base object. Inan embodiment of the present invention in accordance with the LDAP, thesearch may be limited to the base object. Additionally, the scope mayspecify a single level wherein the immediate children of the base objectare also searched. The search scope may also be subtree. In a searchhaving subtree scope, the base object and all descendants thereof aresearched. Additionally, the search parameters may include a searchfilter. The search filter specifies the criteria that an entry mustmatch to be returned from a search. The search filter is a booleancombination of attribute value assertions. An attribute value assertiontests the value of an attribute for equality, less than or equal, etc. Asearch request may also specify the attributes to be returned. Thisparameter lists which attributes are to be retrieved from entries thatmatch the search criteria.

[0024] A search request in accordance with the principles of the presentinvention also may include parameters for selectively enabling objectsreferenced in an entry to also be searched. A chase reference parameterconstitutes a “flag” which enables a search of attribute valuesconstituting a reference to another object in the DIT. (A clientapplication in accordance with the principles of the present inventionmay initiate a search by invoking an Applications Program Interface(API) which includes the aforementioned parameters in the API call. AnAPI for performing LDAP operations is discussed in the commonly ownedU.S. Pat. No. 6,085,188 of Bachmann, et al. which is hereby incorporatedin its entirety herein by reference. Additionally, a schema inaccordance with the principles of the present invention defines a DN_Refsyntax. The DN_Ref syntax may have the same format as the DN syntax.Attribute types having the DN_Ref syntax maybe used to retrieve theobjects painted to by the value of the attribute belonging to such anattribute type. The value corresponds to a referenced object in the DIT.This will be discussed further hereinbelow in conjunction with step 308.The search parameters in accordance with the principles of the presentinvention also include a chase level. The chase level may be used tospecify how many levels of referenced objects will be returned. Thiswill also be discussed further hereinbelow.

[0025] In step 306, it is determined if an object within the scope ofthe search (as specified in the scope parameter retrieved in step 304)matches the value in the filter parameter of the request. If not, instep 308 it is determined if the search scope is exhausted, and if not,methodology 300 searches the next node in the scope, step 310. Theprocess loops over steps 306-310 until either a match is found, or thescope is exhausted, wherein the process terminates, step 311.

[0026] If, however, in step 306 a match is found, in step 312, theselected attributes (in accordance with the attribute list in theattribute parameter retrieved in step 304) are returned.

[0027] As discussed above, the search request may set a chase referenceparameter. In step 314, it is determined if the chase referenceparameter is “TRUE”. If so, in step 316 it is determined if anyattributes in the base object are attribute types having the DN_Refsyntax. This may be determined, for example, by reference to the schemafor each attribute type appearing in the entry for the base object, thatis, the entry having the DN retrieved from the search request in step304. This may be understood by considering a specific example withreference to FIG. 4 which schematically illustrates a simplified DIT 400in accordance with the principles of the present invention. DIT 400includes a plurality of nodes 402-432. Node 402 is the root node. Twochild nodes of root 402, nodes 404 and 406 contain the country (C)attribute having the values “GB” (Great Britain) and US (United States).Node 406 has two child nodes, node 408 and node 410. Node 408 includesthe office (O) attribute having the value “IBM” and node 410 has the Oattribute having the value “NETSCAPE”. Additionally, node 406 has threechild nodes, 412, 414 and 416, each containing the attribute “SYSNAME”with values “HP_(—)1”, “NT_TIVOLI” and “NOTES_TIVOLI”. (Recall that theRDN for anode is an attribute of the node. The attribute that is the RDNis written in the form <ATTRIBUTE TYPE>=<ATTRIBUTE VALUE>. Otherattributes are written in the form <Attribute Type>:<Attribute Value>).

[0028] Nodes (equivalently entries) 414 and 416 also include the Commentattribute type. The value of the Comment attribute in node 414 is “NTDomain” and the value of the Comment attribute in entry 416 is “NotesServer.” (Note that entries inherit the attributes of the nodes fromwhich they descend. Thus, for example, nodes 414-416 include theinherited Country attribute having the value “US.” Inherited attributesare not shown in FIG. 4.)

[0029] Node 408 has two child nodes 418 and 420. Each of nodes 418 and420 includes the Organizational Unit (OU) attribute type. The value ofthe OU attribute in node 418 is “IBM AUSTIN.” The value of the OUattribute in node 420 is “TIVOLI.” Node 418 has further child nodes,nodes 422 and 424. Each of these includes the Common Name (CN) attributetype with the respective values “JOHN FOO” and “MARY BUR.” Similarly,node 420 has a child node 426 with the CN attribute value PETER WANG.”Additionally, node 426 includes three attributes of type “Account.” Inaccordance with the principles of the present invention, the Accountattribute type has the DN_Ref syntax. Referring again to nodes 412, 414and 416, note that each of nodes 412, 414 and 416 has a correspondingchild node, node 428, 430 and 432, respectively. Node 428 has an RDN“ACCOUNTNAME=PWANG.” Similarly, nodes 430 and 432 have an RDNACCOUNTNAME=PWANG. However, in accordance with the LDAP, each of nodes428, 430 and 432 has a unique DN which corresponds to the value of oneof the Account attributes in node 426.

[0030] Thus, returning to FIG. 3, step 308, in the exemplary DIT of FIG.4, the Account attributes in node 426, each have the DN_Ref syntax.Consequently, a search request, received in step 302, the scope of which(in accordance with the parameters retrieved in step 304) which reachedto node 426 and which matched a search filter (also retrieved in step304) would, because at least one attribute (the Account attributes inthe node found) satisfied the condition in decision block 316, searchprocess 300 would proceed by the “Yes” branch of step 316.

[0031] Process 300, in step 318, returns the attributes for each entrypointed to by the value, of each attribute having the DN_Ref syntaxdetermined in step 316. Note that the attributes returned instep 318would be selected in accordance with the search parameter attribute listretrieved from the search request in step 304. Referring to theexemplary DIT 400 in FIG. 4 and assuming, for the purposes ofillustration, that the list of attributes to be returned from eachmatching entry is empty, wherein all attributes of each entry will bereturned in accordance with the LDAP specification, step 318 will returnthe three attributes in each of nodes 428, 430 and 432. That is, theattribute value “PWANG” of the ACCOUNTNAME attribute, the value of theUser Identifier (UID) attribute (“pwang”) and the value “xxx” of the“UserPassword” attribute will be returned from entry 428. The values ofthe corresponding attributes from nodes 430 and 432 will similarly bereturned, in step 318. Note that if the attribute list search parameter,retrieved in step 304, was not empty, an subset of the attributes inentries 428, 430 and 432 would be returned. For example, if theattribute list specified the UserPassword attribute, only the values ofthat attribute, “xxx,” “yyy” and “zzz,” respectively, would be returnedin step 318. (It would be understood by an artisan of ordinary skillthat retrieval of attributes such as the UserPassword attribute may beprecluded by other considerations, such as access controls. For thepurpose of illustration herein, it is assumed that access to theUserPassword attribute is not so restricted.)

[0032] Methodology 300 may “chase” all references appearing as attributevalues depending on the value of the chase level parameter received inthe search request, as discussed hereinabove. This may be performed bylooping over steps 316-320. In step 320 it is determined if the value ofthe chase level parameter is greater than one and the chase notcomplete. If, in step 320, the value of the chase level parameter isgreater than one and the chase is incomplete, process 300 returns tostep 316 and if, any attributes in the current reference which had beenreturned in step 318 are in the DN_Ref syntax then, step 316 returns tostep 318 to return the attributes for those references. If, however, instep 316 there are no attributes having the DN_Ref syntax, then thechase is complete, step 322, wherein step 320 falls through the “No”branch. (Step 314 may be performed, for example, by setting a flag,which flag is tested in step 320, and which flag may be set when theaforementioned chase level counter reaches a predetermined count, suchas zero. However, other implementations of steps 316-322 would be withinthe knowledge of ordinarily skilled artisans in the data processingarts, and such implementations would be in the spirit and scope of thepresent invention.)

[0033] In step 324, it is determined if the value of the chase levelparameter is −1. If step 320 fell through the “No” branch because achase having a chase level greater than one completed, then necessarilythe value of the chase level cannot be −1, and step 316 also fallsthrough the “No” branch. If, however, step 312 fell through the “No”branch because the chase level was not greater than one (that is, eitherzero or a negative value) then it is determined, in step 316, if thechase level is −1. (An artisan of ordinary skill would understand thatalternative embodiments of the present invention may implement otherdecision values for the chase level parameter, which embodiments wouldbe within the spirit and scope of the present invention.) If so, then instep 326 the selected attributes, in the attributes parameter retrievedfrom the search request in step 304, are returned for all nodes pointedto by a reference, that is a value of an attribute having the DN_Refsyntax. If, however, the value of the chase level parameter is not −1,step 326 is bypassed.

[0034] Process 300 returns to step 308 to complete the search inaccordance with the value of the scope parameter in the search request,as previously discussed above.

[0035] In this way a methodology for searching references without havingto retrieve a DN of a referenced object and issue a base search on eachobject is provided. A predetermined syntax for a reference attribute isspecified within the directory scheme. The values of instances ofreference type attributes provide a pointer to the referenced objectwhich pointer may be used to return the attributes of referencedobjects. The depth to which referenced objects are chased may bespecified in the search request.

[0036] Although the present invention and its advantages have beendescribed in detail, it should be understood that various changes,substitutions and alterations can be made herein without departing fromthe spirit and scope of the invention as defined by the appended claims.

What is claimed is:
 1. A search method comprising the steps of:determining if a first parameter has a first predetermined value; and ifsaid first parameter has said first predetermined value, returning avalue of each of one or more selected members of a first node, saidfirst node being referenced by a value of a first member of a secondnode in response to said first member of said second node having apredetermined type.
 2. The method of claim 1 further comprising the stepof determining if a second member of said second node matches a value ofa second parameter.
 3. The method of claim 2 wherein said step ofreturning said value of each of one or more members of said first nodeis in response to said second member of said second node matching saidvalue of said second parameter.
 4. The method of claim 1 furthercomprising the step of returning values of a selected set of members ofsaid second node.
 5. The method of claim 4 further comprising the stepof determining if a second member of said second node matches a value ofa second parameter, and wherein said step of returning values of saidselected set of members of said second node is in response to saidsecond member of said second node matching said value of said secondparameter.
 6. The method of claim 1 further comprising the step of, ifsaid first parameter has said first predetermined value, returning avalue of each of one or more selected members of a third node, saidthird node being referenced by a value of a first member of said firstnode in response to said first member of said first node having saidpredetermined type.
 7. The method of claim 6 wherein said selectedmembers of said first node and said selected members of said third nodeare selected in response to a value of a second parameter.
 8. The methodof claim 1 wherein said first parameter comprises a parameter of a setof parameters in a search request.
 9. The method of claim 8 wherein saidsearch request comprises a Lightweight Directory Access Protocol (LDAP)search request.
 10. A computer program product embodied in a tangiblestorage medium, the program product comprising a program of instructionsfor performing the method steps of determining if a first parameter hasa first predetermined value; and if said first parameter has said firstpredetermined value, returning a value of each of one or more selectedmembers of a first node, said first node being referenced by a value ofa first member of a second node in response to said first member of saidsecond node having a predetermined type.
 11. The program product ofclaim 10 further comprising instructions for performing the step ofdetermining if a second member of said second node matches a value of asecond parameter.
 12. The program product of claim 11 wherein saidinstructions for performing step of returning said value of each of oneor more members of said first node are performed in response to saidsecond member of said second node matching said value of said secondparameter.
 13. The program product of claim 10 further comprisinginstructions for performing the step of returning values of a selectedset of members of said second node.
 14. The program product of claim 13further comprising instructions for performing the step of determiningif a second member of said second node matches a value of a secondparameter, and wherein said instructions for performing step ofreturning values of said selected set of members of said second node areperformed in response to said second member of said second node matchingsaid value of said second parameter.
 15. The program product of claim 10further comprising instructions for performing the step of, if saidfirst parameter has said first predetermined value, returning a value ofeach of one or more selected members of a third node, said third nodebeing referenced by a value of a first member of said first node inresponse to said first member of said first node having saidpredetermined type.
 16. The program product of claim 15 wherein saidselected members of said first node and said selected members of saidthird node are selected in response to a value of a second parameter.17. The program product of claim 10 wherein said first parametercomprises a parameter of a set of parameters in a search request. 18.The program product of claim 17 wherein said search request comprises aLightweight Directory Access Protocol (LDAP) search request.
 19. A dataprocessing system comprising: circuitry operable for determining if afirst parameter has a first predetermined value; and circuitry operablefor, if said first parameter has said first predetermined value,returning a value of each of one or more selected members of a firstnode, said first node being referenced by a value of a first member of asecond node in response to said first member of said second node havinga predetermined type.
 20. The system of claim 19 further comprisingcircuitry operable for determining if a second member of said secondnode matches a value of a second parameter.
 21. The system of claim 20wherein said circuitry operable for returning said value of each of oneor more members of said first node is operable in response to saidsecond member of said second node matching said value of said secondparameter.
 22. The system of claim 19 further comprising circuitryoperable for returning values of a selected set of members of saidsecond node.
 23. The system of claim 22 further comprising circuitryoperable for determining if a second member of said second node matchesa value of a second parameter, and wherein said circuitry operable forreturning values of said selected set of members of said second node isoperable in response to said second member of said second node matchingsaid value of said second parameter.
 24. The system of claim 19 furthercomprising circuitry operable for, if said first parameter has saidfirst predetermined value, returning a value of each of one or moreselected members of a third node, said third node being referenced by avalue of a first member of said first node in response to said firstmember of said first node having said predetermined type.
 25. The systemof claim 24 wherein said selected members of said first node and saidselected members of said third node are selected in response to a valueof a second parameter.
 26. The system of claim 19 wherein said firstparameter comprises a parameter of a set of parameters in a searchrequest.
 27. The system of claim 26 wherein said search requestcomprises a Lightweight Directory Access Protocol (LDAP) search request.